new charger template: TeslaLogger #13062
Conversation
Co-authored-by: andig <cpuidle@gmx.de>
|
@Adminius sollte alles bereit sein? Du kannst jetzt auch |
| enabled: | ||
| source: http | ||
| uri: {{ .url }}:{{ .port }}/currentjson/{{ .id }} | ||
| jq: .charging |
There was a problem hiding this comment.
Das passt nicht: hier gehts drum, ob Ladefreigabe erteilt ist, also charge_amps > 0?
There was a problem hiding this comment.
Was genau macht enabled?
Mit der aktuellen Lösung meckert EVCC ab und zu "out of sync"
There was a problem hiding this comment.
Gibt an ob Laden freigegeben ist. Das Gegenstück zu enable.
There was a problem hiding this comment.
Hm, da könnte man eine Kombinaion nehmen: Ziel SoC unter Aktuellem SoC. Plugged-in wird eh schon ausgewertet.
Was besseres fällt mir nicht ein
There was a problem hiding this comment.
Darum gehts nicht. Es geht nur darum ob evcc die Ladung freigegeben hat. Im Zweifel Freigabestrom > 0A?
There was a problem hiding this comment.
Wie würde die Lösung aussehen wenn ich es in TeslaLogger einbauen würde.
Das wäre wohl eine Option...
Evtl. habe ich die Logik immer noch nicht verstanden 🤔
Stell Dir das als schaltbare Steckdose vor. Die ist an oder aus, unabhängig davon ob ein Stecker steckt oder das Gerät lädt. evcc würde die Dose zwar nicht einschalten wenn kein Auto dran hängt, solang eins dran ist allerdings schon (soc mag gefallen sein, Klimaanlage lief etc).
There was a problem hiding this comment.
Kein Auto daran ist ja Status A
Auto dran, nicht laden ist Status B
Auto dran, laden Status C
Wenn SoC gefallen ist, wird das Auto nachladen, StatusC, egal was EVCC denkt/macht
Nun, beim Status A und B erwarte ich, dass die Dose aus ist, beim C aber an.
Hier also enabled=false bei charging=false
Enabled=true bei charging=true
Oder ist die an beim B+C?
Hier ist es also bei enabled=false: plugged_in=false
Beim True: plugged_in=true
Ich sehe z.B. keine Sinn warum bei Status A eine Dose an sein sollte.
Da wäre enabled=true einfach immer.
War es nicht gleiches Problem bei OpenWB?
There was a problem hiding this comment.
Egal was Du intuitiv erwartest- denk an die Schaltsteckdose. Die schaltet sich auch nicht aus nur weil Du das Ladegerät abziehst...
Nun, beim Status A und B erwarte ich, dass die Dose aus ist, beim C aber an.
Dann erklär mir mal bitte, wie Du in Status C kommen willst wenn die Steckdose ausgeschaltet ist???
There was a problem hiding this comment.
Dann erklär mir mal bitte, wie Du in Status C kommen willst wenn die Steckdose ausgeschaltet ist???
Status B: enable = false, Steckodse ist aus (Schütze in der Wallbox)
Status C: enable = true, denn zum Laden muss man die Steckdose einschalten (Schütze in der Wallbox)
Bei der Steckdose wissen wir auch nicht, dass etwas angeschlossen ist, bei der Wallbox/ dem TeslaLogger schon ;)
So oder so: ich kommen zu meiner Frage zurück: was muss ich in TeslaLogger programmieren, damit EVCC zufrieden ist? Einfach EVCCs enable "merken" und als "enabled" zurückgeben ist wohl nicht der Sinn der Sache, oder? Das könnte man bestimmt direkt in EVCC mit Script und Variablen lösen, oder?
Ich lade an einem mobilen Charger, ohne jegliche Schnittstelle, so ist die Idee auch entstanden über das Tesla zu regeln.
Nun, wenn ich Kabel anstecke und Tesla keinen Timer hat und SoC und Ziel SoC liegt startet der Ladevorgang sofort. Auch wenn EVCC jetzt enabled=false erwarten würde (z.B. zu wenig Überschuss), läuft der Ladevorgang schon, EVCC ist beleidigt, "disabled, but charging" (oder so ähnlich).
D.h. eigentlich müsste man komplette Wallbox Logik nachbauen: merken was die "externen" wollen: enable=false und sobald man Kabel einsteckt Ladevorgang sofort beenden und warten bis enable=true kommt. Dann würde auch enabled von false auf true erst dann wechseln wenn EVCC Ladevorgang erlaubt.
Nun, im Auto/in der TeslaApp kann ich den Ladevorgang aber trotzdem starten -> enable steht immer noch auf false. Also wird der wieder beendet. Ich will aber laden, jetzt. D.h. da müsste ich zuerst EVCC aufrufen um Ladevorgang zu starten. Ist das auch bei den "richtigen" Wallboxen so?
Aber auch hier, kann zu "out of sync" kommen, wenn das Timing nicht passt und EVCC die Daten in der "falschen" Sekunde abruft. Also eigentlich müsste man auch "gefilterten" isCharing Status vorgaukeln, d.h. isCharing = false, obwohl der Ladevorgang beginnt und TeslaLogger ihn aber gleich beenden wird.
So eine Programmierung wird aber wohl länger dauern... Wir wollt ihr das in der Tesla Integration lösen? Oder (noch) gar nicht?
There was a problem hiding this comment.
So oder so: ich kommen zu meiner Frage zurück: was muss ich in TeslaLogger programmieren, damit EVCC zufrieden ist? Einfach EVCCs enable "merken" und als "enabled" zurückgeben ist wohl nicht der Sinn der Sache, oder? Das könnte man bestimmt direkt in EVCC mit Script und Variablen lösen, oder?
Aktuell gibts das nicht weil evcc davon ausgeht, dass sich eine WB ein- und ausschalten lässt. evcc stört sich dran wenn es a) nicht den erwarteten Wert bekommen (Wallbox neu gebootet?) oder b) der Wert nicht zu den anderen passt, z.B. disabled but charging.
Wir wollt ihr das in der Tesla Integration lösen? Oder (noch) gar nicht?
Was meinst Du? Beim TWC machen wir das so:
// Enable implements the api.Charger interface
func (c *Twc3) Enable(enable bool) error {
// ignore disabling when vehicle is already disconnected
// https://github.com/evcc-io/evcc/issues/10213
status, err := c.Status()
if err != nil {
return err
}
if status == api.StatusA && !enable {
c.enabled = false
return nil
}
v, ok := c.lp.GetVehicle().(api.ChargeController)
if !ok {
return errors.New("vehicle not capable of start/stop")
}
err = v.ChargeEnable(enable)
if err == nil {
c.enabled = enable
}
return err
}und Enabled() macht einen Workaround:
// Enabled implements the api.Charger interface
func (c *Twc3) Enabled() (bool, error) {
return verifyEnabled(c, c.enabled)
}
// verifyEnabled validates the enabled state against the charger status
func verifyEnabled(c api.Charger, enabled bool) (bool, error) {
if enabled {
return true, nil
}
status, err := c.Status()
// always treat charging as enabled
return status == api.StatusC, err
}Mit anderen Worten: in diesem Fall speichern wir einfach den vorgegebenen Wert und geben ihn gleichzeitig an das Fahrzeug weiter (ein/aus). Für die Abfrage geben wir ihn zurück und validieren ihn nochmal gegen den Status der Wallbox.
|
Once this is merged it would be great to post in TFF that this provides TESLA-only charging support in evcc ;) |
This comment was marked as off-topic.
This comment was marked as off-topic.
you can use it without merging: Put the right TeslaLogger IP-address and Port and carID (in my example is 3) |
|
I tried, but get this error: |
Is "3" at the end the right CarID in your case? |
|
Ohh no. It is 1. I changed it, but same error... And just to confirm, for "vehicle" I added one vehicle with teslalogger template (id:1) |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@Adminius sollen wir hier nochmal einen Anlauf machen? Das Enable/Enabled ist ja nur insofern unschön, als dass es zu Unmengen von Fehlermeldungen führt und im Zweifel zuviele Requests macht. Evtl.- ich hab das allerdings nicht ausprobiert- könnte man statt |
|
Hey @andig ja, das könnte man noch probieren. Deswegen fokussiere ich mich doch auf die TeslaLogger-WallBox API, damit ich solche Befehle gar nicht erst ans Auto weiterleite. EDIT: und noch etwas: ich kann nicht öfter als 45 Sek Aktualisierung einstellen, weil Tesla nicht schneller reagiert. |
Das ist spannend. In Status A sollte das eigentlich nicht passieren weil es ja nix zu disablen gibt. Hast Du davon evtl. noch ein Logfile? Anders wäre es wenn schon Status C käme- dann denkte evcc natürlich, das Fahrzeug wäre lokal angeschlossen.
Aktuell nicht geplant :O. Du kannst natürlich ein langsames Intervall von 1m einstellen. |
|
Logfile habe ich nicht mehr. Das war schon vor ein paar Wochen und weil ich weit weg von Zuhause war, wäre es auch nicht leicht an die Logs zu kommen (außer Screenshots vom Smartphone). Ich versuche mal die Tage das wieder nachzustellen. Aber was bringt mir noch längerer Intervall außer dass ich noch länger auf eine Aktualisierung warten muss was ich ja vermeiden will? |
Das ist zum Glück ja "nur" optisch. Und: wenn Du in evcc eine Aktion wie Knopfdruck (Moduswechsel etc) triggerst passiert immer ein Update. |
|
ja genau, das ist nur die Optik, die mich verwirrt :D |
|
Zur Info... |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
Hey @andig bin gerade unterwegs und am Supercharger geladen. EVCC container war tot und dann habe ich gestartet. Die Ladung am Supercharger wurde entsprechend gestoppt... Jetzt ist EVCC an, mal schauen was EVCC am nächsten Supercharger macht. |
|
Bräuchte mal ein Log, nicht nur einen unleserlichen Schnipsel |
|
Achso: der Fehler ist der gleiche wie oben- du schickst halt enabled… |
|
Ach, good point, ich habe jetzt ergänzt, dass Enebled=true auch nur "Zuhause" gesetzt wird. |
|
So, nun Das löst mein o.g. Problem, dass auch die DC-Charging gestoppt wird. Hacken dran. "Enabled" macht bei meiner Idee keinen Sinn, dann egal was EVCC will, charging kann man nicht disablen, maximal stoppen. Nun könnte man enabled=enable setzen. Das kann trotzdem zum OutOfSync führen, wenn EVCC disablen will, was gar nicht geht und Tesla wieder anfängt zu laden. Log:
[lp-1 ] DEBUG 2024/05/28 09:44:25 charger status: C Da weiß ich aber die ID nicht, wenn es mehrere Charger gibt. Ich habe noch folgende Idee hier gefunden: #876 damit wird zwar "enable" gespeichert, aber nicht der Tesla gesteuert... |
|
@andig ideen wie ich unter "enabled:" an ${enable} dran komme? kann ich das überhaupt?
-> liefert true
-> liefert nichts: |
|
Ich verstehe die Frage nicht. Reden wir von enable(false) das keine Ausgabe produziert? |
Variable ${enable} ist die Vorgabe von EVCC an die Wallbox, richtig? Wie kann ich den Wert von ${enable} direkt unter "enabled:" (also Antwort von der Wallbox) Sektion als Antwort dem EVCC zur Verfügung stellen. |
|
Entweder extern oder intern round-trippen. Extern hast Du oben stehen. Intern mit Go oder JS Plugin die sich eine "vm" teilen und die gleiche Variable verwenden. Sie demo.yaml für Beispiele. |
Refs #13046, depends on #13056